As the AD noted, the list has been inactive for the last few weeks.

In this email I am trying to summarize where we are and what we need to do next in the WG:

1. use cases: We had a long discussion about the use cases in the last f2f, and it seems that the only use case requiring a re-write is the m2m one. Juan-Carlos promised to revise the use case based on the comments received and post the revised version to the list asap.
Brian promised to contribute a use case on mesh-networking, as that seems to be different from the m2m one.
With the revision of the m2m and addition of the mesh-networking one, the use case part should be complete.

2. requirements. In the last f2f 
we agreed to modify requirement D.1 to include the suggestions from slide 7-10 of http://www.ietf.org/proceedings/82/slides/paws-2.pdf and merge with D.6 and D.9
slides 7&8 of http://www.ietf.org/proceedings/82/slides/paws-1.pdf also contain suggestions on how to revise this requirement.
Agreed to revise requirement D.2 as suggested in slide 11 of http://www.ietf.org/proceedings/82/slides/paws-2.pdf and slide 9 of http://www.ietf.org/proceedings/82/slides/paws-1.pdf 
We seem to have agreed with the reformulation suggested to D.3 in slide 12 of http://www.ietf.org/proceedings/82/slides/paws-2.pdf, but we did not agree on the format the location would be represented in. The data format part is still open, but as this piece does not really belong to requirements but rather the data model spec, we are not in a hurry to decide it.
Delete d.4
D.5: augment with lower/upper frequencies and time of availability, as suggested on slide 10 of http://www.ietf.org/proceedings/82/slides/paws-1.pdf 
D.6: change power to eirp, as suggested in slide 13 of http://www.ietf.org/proceedings/82/slides/paws-2.pdf.
D.7: change to single and multiple locations. Clarify that in case of multiple locations the channel availability for each location should be sent by the db.
D.8: delete

P.2 currently says: The protocol MUST support regulatory domain discovery.
We need to discuss this further on the list, to come up with a better formulated requirement.
The minutes captured:
Implies transmitter first queries the DB to find out the regulatory domain before it queries for the available channel list
need to spend time figuring out an implementable requirement.  Related to sending "rules" for a domain
put it as a suggestion rather than requirement.  Current regulations envision tight coupling between certified devices and owners.
need to document the coupling between regulatory domain, database, requirements.
Suggestions for P.2 expected to the list.

P.3 currently says:  The protocol between the master device and the WS Database  MUST support pushing updates in channel availability  changes to subjects.
There were comments that this requirement involves a mechanism, we should reformulate to be mechanism agnostic.
There was a suggestion to "make the requirement "quick way to change availability" rather than imply a mechanism.".
The use case is that if the channel availability changes in the DB, the client has to be able to detect it and get the new availability list within a time period set by the regulator.
Can someone send suggested text on how to reformulate this requirement?

We had no time to go through these requirements, so I am asking here on the list to please comment on them:

P.4:   The protocol between the master device and the WS Database
             MUST support mutual authentication and authorization.

P.5:   The protocol between the master device and the WS Database
             MUST support integrity and confidentiality protection.

P.6:   The protocol MUST support both username/password and
             digital certificates based authentication.

P.12:  A master device MUST be capable of validating the digital
             certificate of the WS Database.

P.13:  A master device MUST be capable of checking the validity of
             the WS Database certificate and whether it has been revoked
             or not.

Note, P.13 requires support for OCSP (RFC2560) in the client, I am not sure if that is needed, please send your opinions.

The wording of P.11 has to be enhanced to match the description of the revised D.1


We did not have any discussion on P.9, so I'd like to get comments on the list about this:
      P.9:   A master device MUST be able to query the whitespace
             database for channel availability information for a
             specific expected coverage area around its current
             location.

Operational requirements: slides 22-24 of http://www.ietf.org/proceedings/82/slides/paws-2.pdf contain suggestions on rewording, I propose the editor considers them.

I ask the editor to implement the changes above and post a revised version asap, so we can have further reviews on it.


We also have a protocol framework document available at http://www.ietf.org/id/draft-das-paws-protocol-00.txt
We did have a brief discussion on it, the author promised to update it to capture the received comments and post a new version in the next few weeks. If you have additional comments, please send those to the list, so the author can address them.

We also have a proposal available on the data model structure, available at http://www.ietf.org/id/draft-caufield-paws-protocol-for-tvws-01.txt
It was presented in the last f2f, but there was no time for comments. Please send your comments on this document to the list too.

- Gabor